When replication is enabled, any new value (whether the value is the result of an edit, addition, or delete) is written to a change queue by the source service. The change queue is stored in memory, so internal access to it is very fast. Each item in the change queue is given a unique sequence number by the source service. The sequence number is incremented each time a change is made, and a sequence number is assigned to that change.
The size of the source service's change queue is specified by the CHANGE_QUEUE_SIZE keyword in the source service's configuration file (.cfg). The keyword configures the number of entries allocated on the change queue. The default value differs by service, but 100,000 is the default for most services. If no value is specified, then the minimum size will be used by default.
Keep in mind that setting a large CHANGE_QUEUE_SIZE for a service such as the ELS can be costly. However, if the CHANGE_QUEUE_SIZE is too small for a DBS-based service, it is more likely to rollover and trigger a full resynchronization too frequently, which may also place undue burden on the system. For most services, the default value of 100,000 is sufficient.
All non-Historian services write a record of their new values to a change queue, including replicated services. This allows replicated services to serve as the source service to another replicated service. If there is no additional replication you may wish to turn the change queue off for the replicated service, since it is unnecessary. To disable the change queue for the replicated service, uncomment the CHANGE_QUEUE_SIZE keyword in the replicated service’s configuration file and set its value to 0.
Many CygNet services handle aspects of replication uniquely. Read the following sections for more information.
When replication is enabled in the CAS or a CVS, any new value is written to the source service’s change queue. When the replicated service is started a full resynchronization is triggered automatically, during which all records are compared against the source service and updated in the replicated service. Once the full resynchronization is complete the replicated service continues to check for any new changes in the source service and updates itself accordingly. Whenever the change queue rolls over, the source service stops, or the replicated service stops a full resynchronization is triggered, after which the incremental replication is resumed.
As with the DBS-based services, the change queue is maintained in memory by the source. In some cases, pending GNS, CAS, and VHS notifications may be lost in the event of system loss.
The CAS is able to forward commands (such as acknowledgment requests) by writing the commands in XML format to a specified location on the replication server. The CAS will validate the request and if command forwarding is configured, will write out the command and the associated information to an XML file. During startup the CAS will process and delete these files as necessary. See Replication Command Forwarding for more information.
When replication is enabled in a DBS-based service, any new value (whether the value is the result of an edit, addition, or delete) is written to a change queue. The change queue is maintained in memory by the source. Each item in the queue is given a unique sequence number by the source service. The replicated service keeps track of the sequence number of the last record it received. If the sequence numbers match it indicates that the replicated service is up to date with the source service. If the sequence numbers of the most recent records are different, it indicates that there have been new changes to the source service. This triggers the replicated service to retrieve the new value from the source service.
When the source service is shut down in a normal fashion, the information in the change queue is written to the file .replnotify in the source’s service folder. When the service is restarted, the information from the file is written to the queue and replication operations resume. If the service has an abnormal shutdown, a complete resynchronization is triggered on service restart.
If the replicated service is not running and the source service’s change queue rolls over, when the replicated service is restarted it will begin a full resynchronization. Once a full resynchronization has been triggered the replicated service begins comparing and updating the most recent record and continues until it reaches the oldest record. While this resynchronization of "older" data is happening it keeps replication of new record changes as the top priority. These "new" changes are processed before the resynchronization of the "older" changes continues. This process continues until all records are up to date and then the normal replication process continues comparing sequence numbers against the source service and updating accordingly.
By default, DDS transaction records are not replicated from the source service to the replicated DDS. When any entry in a device record changes (with the exception of a transaction record), a full resynchronization of that device record will be triggered. When the replicated service resyncs the device record it will also copy over the transaction records.
Optionally, DDS transaction record replication for remote devices can be enabled for each data group through the Data Group Properties dialog box, as well as via the CxDds API and ODBC. See Data Group Properties for more information about this option.
Use the ReplValidator Utility to make sure that all tables in both the source and replicated DDS services are identical. If Transaction Replication is disabled for a data group the utility will note that in its test results (by Db key) and skip replication evaluation for the relevant transaction records.
See FMS Replication and Data Synchronization for more information about how replication works for CygNet Measurement.
If you replicate a SVCMON, be aware that the data in the replicated service is data from the source system. For example, if the source SVCMON has a point to monitor available disk space, the value of the point applies to the source system and not the replicated system.
You may want to run a non-replicated SVCMON to monitor the replicated system.
By default a replicated UIS operates in read-only mode and cannot execute UIS commands, or get and send data groups. However, a replicated UIS can be configured to forward UIS commands to its source UIS. If the command is configured as an allowed command, when a user attempts to execute the command from the replicated UIS, it will be passed back to the source service, at which point the source service will check security for the user and if appropriate, execute the command.
To enable this feature, the ALLOWED_REPL_COMMANDS configuration keyword must be enabled and defined in both the replicated and the source UIS configuration files. This specifies which commands may be forwarded by the replicated service and which may be accepted by the source service. The keyword value is a list of UIS Command Names, separated by a space. Up to ten UIS commands can be configured as allowed commands. If specifying multiple commands, no spaces are allowed in the command names unless each individual command containing spaces is surrounded by quotes, for example, "CMD 1" "CMD 2" "CMD 3". See UIS Configuration File Keywords for more information.
Note: This feature only works via Script.
A special token "EX_UIS_CMD" in the ALLOWED_REPL_COMMANDS keyword allows the forwarding of any UIS command without needing to specify the command in the keyword, and without limiting the user to ten commands. The special token must be specified in the keyword in both the UIS configuration file on the production and replicated sites.
VHS replication uses a pull model for replication like all other CygNet services that support replication. In this model, one or many services may replicate data from a source VHS. The replicated services are responsible for pulling data from the source service, which relieves the primary VHS of the burden of replication and distributes it to the replicated services instead. This prevents replication from negatively impacting the primary active VHS.
See VHS Replication for more information about how replication works for the VHS.
|
|
|
